1. Problems with the implementation of Recurrences on Mobile Devices

Although mobile calendar synchronization solutions have matured over the past years, providing for the most part reliable mobile-side representations of user’s calendar information, severe problems can exist with synchronization of repeating events. Often the calendar on the device does not accurately reflect irregular or changing instances of repeating events on the server. This basic mismatch can then turn into corruption of the server data if these irregularities are sent back to the server for example in the case where an OMA Data Synchronization slow sync might be triggered.

There are several causes of mismatched device and server recurring events that are directly related to the way in which devices support IETF RFC 2445 (in many cases vCal).

  • Some devices do not support either sending or receiving RDATE or EXDATE although they support RRULE.

  • Some devices support one or the other.

  • Some devices don’t support any of the three.

For implementers that insist on continuing to use vCal rather then IETF RFC 2445 there is the issue that vCal does not support the notion of making any changes to an instance of a recurring event other than rescheduling the start time and date; yet many events also change their LOCATION. The use of the IETF RFC 2445 RECURRENCE-ID property would easily solve this issue but implementers need to be willing to move to IETF RFC 2445.

Even if an implementation supports RRULE the actual set of rules that the implementation can handle is normally far less then what is defined in IETF RFC 2445.

One large underlying problem surrounds the misinterpretation of the OPTIONAL nature of some properties in vCal and IETF RFC 2445. This has lead to the belief that supporting the full set of properties is not required, resulting in poor interoperability between products that support different sub-sets of properties.

In order to deal with these interoperability problems there needs to be a proper understanding between client and server implementers on what should be supported. The next section defines three levels of support. The two sections following it provide recommendations on how both device implementations and server implementations should deal with each level.